Skip to content

ci: add issue welcome issue - #4127

Closed
Phoenix500526 wants to merge 1 commit into
apache:mainfrom
Phoenix500526:action/issue-welcome
Closed

ci: add issue welcome issue#4127
Phoenix500526 wants to merge 1 commit into
apache:mainfrom
Phoenix500526:action/issue-welcome

Conversation

@Phoenix500526

Copy link
Copy Markdown
Contributor

Summary

So many people don't know that they can reply a "take" or "untake" comment to self-assign or self-unassign an issue. This action is designed to leave a comment on an issue to let them know.

Refs #N

Verification

AI use

Select exactly one:

  • No generative tool made a substantive contribution
  • Generative tooling made a substantive contribution

Tool(s) and scope:

Checklist

  • Tests cover the change and fail without it
  • Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

  • Yes — described under Summary above
  • No

@github-actions github-actions Bot added the effort/S Under 100 readable lines label Aug 29, 2026
@Phoenix500526
Phoenix500526 force-pushed the action/issue-welcome branch 2 times, most recently from c458d05 to 4ee87bd Compare August 29, 2026 03:49

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for thinking about how we can make take / untake easier for contributors to discover.

Since this would add an automated comment to every newly opened issue, I think the behavior itself would be better discussed with the community before we decide on the implementation. The commands are already documented in the contributing guides, so it would also be useful to establish whether there is still a discoverability gap and whether an automatic comment is the preferred way to address it.

Would you mind opening a Discussion for this proposal and linking it here? That would give contributors and maintainers a place to weigh the onboarding benefit against the additional notification and issue noise. This is a suggestion about where to make the product/community decision, rather than an objection to your implementation.

Reviewed with Codex; I verified the existing assignment workflow and contributor documentation.

中文对照

谢谢你考虑如何让贡献者更容易发现 take / untake

由于这个改动会在每个新建 issue 下自动添加一条评论,我觉得在决定具体实现之前,最好先和社区讨论这个行为本身。目前贡献指南里已经记录了这些命令,因此也值得先确认现在是否仍然存在可发现性问题,以及自动评论是不是大家更希望采用的解决方式。

可以请你先为这个提议创建一个 Discussion,并在这里关联一下吗?这样贡献者和维护者可以一起权衡它对新贡献者的帮助,以及额外通知和 issue 噪声带来的影响。这只是建议把产品和社区层面的决定放到更合适的地方讨论,并不是对你当前实现的否定。

本次审查使用了 Codex;我核对了现有的 issue 认领 workflow 和贡献指南。

@Phoenix500526

Copy link
Copy Markdown
Contributor Author

@Astro-Han Thanks for the suggestion. I opened #4160 so the community can discuss the discoverability benefit and notification cost before we move forward with this behavior.

@Astro-Han Astro-Han left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The community/product decision from the earlier review still needs human resolution. Separately, the current exact implementation has one repository-policy provenance issue that can be fixed without deciding whether the feature should ship. Review analysis was assisted by Codex and an independent @Reviewer agent. Astro-Han verified the exact-head workflow and policy before publication and owns this review.

Comment thread .github/workflows/issue-welcome.yml Outdated
Signed-off-by: Jiawei Zhao <Phoenix500526@163.com>

@hqhq1025 hqhq1025 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed exact head d84569a4585220b4b1f34b0a002248389069d917. I found no P0-P3 technical issues in this revision.

The change adds an issues.opened workflow that posts static take / untake guidance. I checked the complete one-file diff against the existing assignment workflow and contributor documentation. The command descriptions match the exact-body behavior, the welcome comment cannot trigger the assignment workflow itself, permissions are limited to issues: write, and the action is pinned to the commit for v5.0.0.

Validation: actionlint v1.7.7, workflow contract assertions, ASF header audit, git diff --check, clean ancestry/merge against current main, and the hosted test check all pass.

The remaining question is product/community policy, not implementation correctness: Discussion #4160 is still open and unanswered, while this change would add a bot comment and notification to every newly opened issue. This technical review should not be treated as approval of that behavior; a maintainer/community decision is still needed before merge.

I did not execute a real issues.opened event because that would require mutating the live repository.

Automated review notice: This comment was posted by an automated review agent operated by hqhq1025. It is not an independent human review and does not replace one.

@Phoenix500526

Copy link
Copy Markdown
Contributor Author

Closed accroding to the discussion: #4160

@Phoenix500526
Phoenix500526 deleted the action/issue-welcome branch September 2, 2026 02:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

effort/S Under 100 readable lines

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants